IBIS Macromodel Task Group

Meeting date: 10 November 2009

Members (asterisk for those attending):
  Adge Hawes, IBM
  Ambrish Varma, Cadence Design Systems
  Anders Ekholm, Ericsson
* Arpad Muranyi, Mentor Graphics Corp.
  Barry Katz, SiSoft
* Bob Ross, Teraspeed Consulting Group
* Brad Brim, Sigrity
  Brad Griffin, Cadence Design Systems
  Chris McGrath, Synopsys
* Danil Kirsanov, Ansoft
  David Banas, Xilinx
  Deepak Ramaswany, Ansoft
  Donald Telian, consultant
  Doug White, Cisco Systems
* Eckhard Lenski, Nokia-Siemens Networks
  Eckhard Miersch, Sigrity
  Essaid Bensoudane, ST Microelectronics
* Fangyi Rao, Agilent
  Ganesh Narayanaswamy, ST Micro
  Gang Kang, Sigrity
  Hemant Shah, Cadence Design Systems
  Ian Dodd, consultant
  Jerry Chuang, Xilinx
  Joe Abler, IBM
  John Angulo, Mentor Graphics
  John Shields, Mentor Graphics
  Ken Willis, Cadence Design Systems
* Kumar Keshavan, Sigrity
  Lance Wang, Cadence Design Systems
  Luis Boluna, Cisco Systems
* Michael Mirmak, Intel Corp.
* Mike LaBonte, Cisco Systems
  Mike Steinberger, SiSoft
  Mustansir Fanaswalla, Xilinx
  Patrick O'Halloran, Tiburon Design Automation
  Paul Fernando, NCSU
  Pavani Jella, TI
* Radek Biernacki, Agilent (EESof)
* Randy Wolff, Micron Technology
  Ray Komow, Cadence Design Systems
  Richard Mellitz, Intel
  Richard Ward, Texas Instruments
  Samuel Mertens, Ansoft
  Sam Chitwood, Sigrity
  Sanjeev Gupta, Agilent
  Shangli Wu, Cadence Design Systems
  Sid Singh, Extreme Networks
  Stephen Scearce, Cisco Systems
  Steve Kaufer, Mentor Graphics
  Steve Pytel, Ansoft
  Syed Huq, Cisco Systems
  Syed Sadeghi, ST Micro
  Ted Mido, Synopsys
  Terry Jernberg, Cadence Design Systems
* Todd Westerhoff, SiSoft
  Vladimir Dmitriev-Zdorov, Mentor Graphics
  Vikas Gupta, Xilinx
  Vuk Borich, Agilent
  Walter Katz, SiSoft
  Zhen Mu, Mentor Graphics

------------------------------------------------------------------------
Opens:

- None

--------------------------
Call for patent disclosure:

- No one declared a patent.

-------------
Review of ARs:

- Arpad modify 10/20/2009 flow to include Use_Init_Output boolean
  - In progress

- Arpad Write a clarification BIRD to discuss accuracy issues related to the 
  various AMI clock_tick algorithms in an IBIS-AMI DLL
  - TBD

- Todd: Update the BIRD for IBIS S-parameter box based on feedback from discussion
  - No update

- Arpad:  Write parameter passing syntax proposal (BIRD draft)
          for *-AMS models in IBIS that is consistent with the
          parameter passing syntax of the AMI models
          - TBD

- TBD:    Propose a parameter passing syntax for the SPICE
          - [External ...] also?
          - TBD

- Arpad:  Review the documentation (annotation) in the macro libraries.
          - Deferred until a demand arises or we have nothing else to do

-------------
New Discussion:

Arpad showed the 10/20/2009 flow slide 1:
- In convolution 3 Use_Init_Output must be true if Tx GetWave_Exists is false
  - This creates 3 different convolution cases
- It doesn't matter where the convolution 4 box is placed in the flow
  - It is placed after convolution 3
- Arpad: Can Rx_Init 2nd expression work with the convolution 4 box?
- Walter: It would have to be deconvolved in that case
  - If Use_Init_Output = true then Rx Init_Returns_Filter must be true
- Kumar: It can not return a filter
- Walter: Correct, but then Rx Init_Returns_Filter should be true
  - We will have to live with that compromise
- We will use the term "preferable" for this

AR: Arpad update flow slides

Brad's connectivity proposal
- System models sometimes concatenate several connectors together
- Thousands of terminals
- Mistakes will be made if typing these
- How can model generation and EDA tools work together?
- Chip-package co-design simulates them together
- Sigrity adds comments to describe connections
- Working with EDA companies on this
- There should be one protocol
- Anyone interested in working on this?
- Arpad: This relates to the EMD proposal
- Walter: EMD is top down, Brad is looking bottom up
  - With enough info the system could build an EMD
- Brad: We want something for a Q1 time frame
  - What forum is best for this?
  - Touchstone could have the same info
- Walter: The port information should be extensible
  - We put port mapping info in side files
- Mike L: Side files are OK for resident project areas
  - Single files are best for distribution to avoid confusion
- Brad: Are we nearly ready to take this on?
- Arpad: A few more meetings are needed for AMI
  - It may take the rest of the year
- Walter: The Wed interconn group is about to turn to TS port mapping
- Arpad: Does this conflict with EMD?
- Walter: This is bottom up, EMD is top down
  - They can co-exist
- Bob: Who else is involved?
- Brad: Can't say, under NDA
  - Some of them can join meetings
- Bob: How far along is the proposal?
- Brad: We will deliver in Q1
- Bob: The other group is working on connectors
- Brad: A package is a connector
  - When we refer to a chip the connector is included implicitly
- Bob: It would have to be made public
- Brad: This was done long ago
  - Some may avoid it because it was created privately
  - IBIS approval may help
  - Sigrity will release documentation with our name stripped off
- Arpad: This will continue in the Wed meetings

Arpad showed some questions from Mentor developers:
- a) Require GetWave to contain fixed number of samples per bit?
  - For example, each GetWave call might have 5, 10, 15, etc bits
  - Mentor says yes
  - Kumar: Should treat all GetWave calls as a continuous waveform
    - This is a difficult problem
  - Walter: Agree
  - Arpad: It would make it easier for the model maker
  - Walter: You can't assume there would always be the same number of samples per bit
  - Arpad: 5 is just an example
  - Walter: What if it is not constant?
  - Kumar: DCD for example
    - They have to handle this with resampling
- b) Are 2^N samples per bit required?
  - Kumar: It has to always be resampled
  - Walter: Agree
  - Bob: Do model developers have a choice in this?
  - Arpad: Only if there is a way to tell the EDA tool
  - Walter: Some algorithms work best with 16 samples per bit
    - The input has to be converted to 16 samples per bit
- c) How many clock ticks can GetWave return?
  - The EDA tool must allocate memory
  - Kumar: It should be the same as the input waveform
  - Arpad: If there are 300 samples I might have only 10 clock ticks
    - It will run millions of bits
  - Walter: You only handle thousands at a time
  - Fangyi: There should be only one -1 at the end of the clock ticks
  - Kumar: In the first spec we had one size for GetWave
  - Walter: There has to be clarification on this
- d) Can GetWave size vary between calls?
  - Walter: We should allow it
  - It would be safer to not change the size
  - Arpad: Init also allocates memory
  - Walter: At Init we don't know how long the GetWave calls will be
    - Only overlap-and-save memory must be allocated by Init
    - GetWave is re-entrant
  - Todd: Init also allocates internal state data
  - Kumar: Memory is allocated by the EDA tool, not the model
  - Arpad: We need to ask model developers
- e) Should clock ticks be aligned with sample times?
  - It should not be
  - Walter: Agree

Arpad: We will discuss our holiday schedule next time

Next meeting: 17 Nov 2009 12:00pm PT

--------

IBIS Interconnect SPICE Wish List:

1) Simulator directives